同样是做 Linux BSP 驱动,在芯片原厂和终端厂有什么不一样

🔍 溯源 ✍️ Jason | 📅 2026-08-28 | 👍 0 | 原帖↗
#知识星球 #立芯嵌入式 #来源/立芯星球 #技术/LinuxBSP #技术/I2C #质量/精华

原帖 | Jason | 2026-08-28 11:20 | 👍0 | 阅读约1

同样是做 Linux BSP 驱动,在芯片原厂和终端厂有什么不一样?

我们直接用课程里的一张图来解释吧,图中是 Linux 中 I2C 子系统的框架。

先说一下为什么以 I2C 来举例呢,因为 I2C 太常用了,不管是 MCU 还是 Soc 必用 I2C,原因是因为 I2C 从协议规范上讲就很严格,几个 bit 位就一定有 ack 或 nack,根源上保证了命令传输的正确性,所以天生 I2C 就是要比其他协议安全和正确。并且 Linux 下 I2C 子系统的驱动框架我觉得具有代表性。

如图所示,正常一个 user 在 Linux 中发起一笔 I2C 传输,就是从上到下整个 flow 都会跑,相当于 i2c 设备驱动、linux i2c core 层、i2c 控制器驱动 三个都会用到。

从实现角度讲,i2c 设备驱动 就是终端厂商linux 驱动工程师的人写的,linux i2c core 层是 linux 内核自带的,i2c 控制器驱动是芯片原厂驱动工程师写的,大家统一遵守 linux 规范,即便互相不认识也可以正常跑,毕竟 API 和 结构体 都是规定好的。

但是实际情况是什么,是终端厂商的驱动工程师,很多时候调试一个 i2c 外设,驱动都是找供应商 vendor 直接拿的,自己配个 dts 设备树就跑起来了,根本没有写驱动,有底层 bug 也是求助芯片原厂的人。所以很多终端厂商的驱动工程师,做了好几年,觉得自己不懂驱动,修修改改就能跑,心里没底。

因此,终端厂商的 Linux 驱动工程师,纯驱动角度理解的少,更多的是专注于设备驱动之上的公司业务逻辑,比如根据用户需求,在设备驱动中实现业务逻辑和跨模块的交互等。而芯片原厂的 Linux 驱动工程师,是真的专注于开发 i2c 控制器驱动,研究 linux i2c core 层机制,研究 Soc 芯片底层实现机制,做最底层的驱动,做驱动兜底的人。

I2C 模块是这样,其他 Linux 驱动模块也是这样。

26cbef7ef977.jpg


相关笔记